perf(enum): for-in builds its shadow set only when a prototype level has a key to filter - #9823

A filter that has never once filtered

js_for_in_keys_value kept a HashSet<String> of every own name at every
prototype level, so a name owned closer to the receiver would hide the same
name further along the chain (ECMA-262 14.7.5, 12.6.4-2). Measured on the
compiled claude-code TUI, one 400-character streamed reply:

Across 17,281 for-in loops, not one key came from a prototype level. The
set cost 159,947 heap allocations and 159,947 hashes per reply and filtered
nothing, ever — not "rarely", zero times.

Those two numbers together are the whole argument. 159,947 executions
holding 1.91 MB is why no allocation-byte ranking could ever have found this:
by bytes it is a rounding error, and the cost is 160,000 mallocs, memcpys,
hashes and frees, which is independent of the bytes. The campaign's
2026-09-05 correction to ARCHITECTURE.md says a category's byte share bounds
the collection schedule and nothing else; this is that in its sharpest form.

For the same reason it was picked correctly before being measured: the two
candidates on the table had byte shares of 7.8 % (for-in) and 6.9 % (string
concat), which are indistinguishable. Reading the per-allocation cost out of
the source separated them — concat is a handle scope, a length computation, one
arena allocation and a memcpy, i.e. cost proportional to bytes, so for concat
the byte share really is the story; for-in was doing a malloc, a memcpy, a
SipHash and a free per key per level. The counters then confirmed the pick at
14x.

What changes

The set can only ever filter a level >= 1, and a level contributing no
enumerable keys of its own never consults it. So it is built on demand — at the
moment a level >= 1 actually has an enumerable key to filter — from exactly the
levels already walked, which is the same content the eager version held at that
point. The emitted key sequence is unchanged.

Half the key arrays go with it: the all-own-names array (the second array per
level, including non-enumerable names) is materialised only once the set is
live.

VisitedLevels keeps the walked levels inline (8, against a measured 2.00 per
call) so the rebuild's bookkeeping does not reintroduce one allocation per
for-in in place of the ones removed.

Rig table

Reference cc_relink/cc_main_0905; this branch's base is d36a1af0c, which is
the same commit that binary is built from. Four rounds, arm order rotated
each round, quiet box (1-min load 5.3-8.5), node in the same session.

The on/off pair is the precise attribution: one binary, one environment
variable (PERRY_FORIN_LAZY_SHADOW=0), so nothing but this change differs.

Paired, run by run:

CPU is flat — the paired deltas have no direction and straddle zero, and I
am not claiming a CPU win. Memory is down ~7 %, lower in 4 of 4 paired runs
on both measures, which is what deleting 159,947 allocations per reply looks
like when they are small and short-lived. Neither metric regresses.

Two controls worth noting. The off arm reproduces cc_main_0905 almost
exactly (4.50 vs 4.54 s, 641 vs 640 MB, 560 vs 558 MB), which is the positive
control for the env gate: it says the gate really does restore today's
behaviour and that the binary is otherwise the reference. And the collection
schedule is unchanged, as predicted in advance for a category this size —
41 vs 43 copying minors, 46 vs 48 budgeted full-cycle steps.

Falsifiers, registered before measuring

Per ARCHITECTURE.md's corrected rule, as a pair:

1. Schedule — predicted flat. Met: 41 vs 43 minors, 46 vs 48 steps.
2. Executions — the actual claim. Required key_strings >= 3x keys_emitted and key_arrays >= 2x calls, else there is nothing redundant
   to remove and I stop. Met at 14.1x and 4.0x.
3. CPU was not predicted, and is reported as the outcome it turned out to
   be: flat.

Ground

Work permanently removed, not made cheaper: the dedupe needs identity, not an
owned String, and the second key array per level is no longer built at all.
That stands on its own even with CPU flat — and the filter is now proven
inert on this workload rather than assumed useful.

Tests

Three, each verified to fail under sabotage (deleting the deferred build fails
two by name; dropping the spill fails the third).

One of them could not fail when first written, and that is recorded in its
doc comment. The deep-chain test originally gave every level the shadowing
property, including the leaf — so deleting VisitedLevels' spill arm left it
passing, because the leaf's own copy shadowed the root's on its own. It is now
shaped so the spilled level is the only thing that can produce the expected
answer, and the comment explains why, so it cannot be "simplified" back into a
test that certifies nothing.

cargo test --release -p perry-runtime --lib -- --test-threads=1: 3,171
passed, 0 failed. cargo clippy -p perry-runtime introduces nothing (the
four hits in this file are pre-existing).

Filed separately, not fixed here

PERRY_ENUM_DIAG also showed js_string_concat_site_value called zero
times against ~8,600 concat calls per reply, and nm shows the symbol is not
in the linked binary at all — the per-site concat cache (#9514) has no call
sites in this workload. That is #9824, deliberately kept out of this PR.

https://claude.ai/code/session_014UZWia6L37DpA93VLtNK9m

Summary by CodeRabbit

• Performance

  • Improved for-in enumeration efficiency by delaying unnecessary shadow filtering work.
  • Preserved existing key ordering and enumeration results, including across complex prototype chains.
  • Added configurable eager-mode behavior for compatibility and performance comparisons.

• Diagnostics

  • Added optional enumeration and string-concatenation diagnostics, including allocation, traversal, and output metrics.
  • Diagnostic reports can be enabled through environment configuration.

• Documentation

  • Documented the new enumeration optimization, configuration options, and performance measurements.